[00:00.000 --> 00:05.200]  Hello, I am Mati Vanhoef and I'm going to give a presentation about our paper titled
[00:05.200 --> 00:12.340]  Protecting Wi-Fi Beacons from Outsider Forgeries. This research was published at the WISEC conference
[00:12.340 --> 00:18.420]  just a few months ago and this was joint work with Prasant Adhikari and Christina Popper.
[00:18.620 --> 00:24.600]  In this presentation I'm going to give a summary of our results. So as the title of the presentation
[00:24.600 --> 00:31.740]  implies, we're going to protect Wi-Fi beacons. Before we get into that, what exactly is a Wi-Fi
[00:31.740 --> 00:38.820]  beacon? Well, Wi-Fi networks use Wi-Fi beacons to announce their presence to nearby clients
[00:38.820 --> 00:46.960]  and they are sent roughly every 100 milliseconds by an access point. These beacons contain various
[00:46.960 --> 00:51.420]  properties of the network. For example, they contain the name of the network,
[00:51.420 --> 00:58.280]  they contain the supported bit range, for example, whether the network supports the 11n or 11ac
[00:58.280 --> 01:05.240]  standard. They also contain certain regulatory constraints, for example, the maximum transmission
[01:05.240 --> 01:12.580]  power and so on. But the problem in practice is that these beacons are not protected and they can
[01:12.580 --> 01:20.660]  be forged by an adversary. In our work, in this presentation, we present novel attacks that abuse
[01:20.660 --> 01:28.080]  beacons and motivated by these novel attacks that we discovered, we implement a defense to prevent
[01:28.080 --> 01:35.260]  outsiders from forging beacons. And we also standardized this defense as part of the 802.11
[01:35.260 --> 01:44.060]  specification that underpins Wi-Fi. And on top of all of this, we also have an implementation on
[01:44.060 --> 01:54.240]  Linux and our defense might even become part of WPA3. But before we get into these details,
[01:54.240 --> 01:59.840]  let's take a step back and look at the history of Wi-Fi security. And here we can see that
[01:59.840 --> 02:06.780]  previously the focus was on protecting transmitted data and not beacons. For example, if we look at
[02:06.780 --> 02:17.400]  on WPA1 and 2, they really focus on protecting data only. Now, WPA3 does mandate that certain
[02:17.400 --> 02:24.280]  management frames are also authenticated. However, unfortunately, this does not include beacons.
[02:24.280 --> 02:32.100]  And even if we look at some very recent additions to Wi-Fi, such as operating channel validation,
[02:32.100 --> 02:36.760]  this only verifies the information about the current channel at the access point.
[02:36.780 --> 02:44.280]  In other words, even if we use all the modern standards,
[02:44.280 --> 02:52.320]  beacons are not protected and they can be forged by an adversary. And if we look at the contents
[02:52.320 --> 02:59.220]  inside a beacon, we see that there's a lot of information that a beacon contains. And a small
[02:59.220 --> 03:06.400]  amount of information is indirectly verified when you connect to the network. For example, the WPA
[03:06.400 --> 03:12.840]  version that is supported by the network on the current operating channel is securely verified
[03:12.840 --> 03:19.840]  when you are connecting to a network. But all the other information that is contained in a beacon,
[03:19.840 --> 03:24.680]  and here we are only showing a small part of the possible information in the beacon,
[03:25.040 --> 03:33.520]  can be spooked by an adversary and possibly be abused. So, the first thing that we did in our
[03:33.520 --> 03:41.200]  research is that we searched for novel attacks that an adversary can carry out by spoofing these
[03:41.200 --> 03:49.840]  beacon frames. One of the first attacks that we discovered is what we call a power-constrained
[03:49.840 --> 03:58.960]  attack. Namely, as I already hinted at previously, beacons contain the maximum allowed transmit power
[03:58.960 --> 04:07.260]  that a client should be using. For example, if we look at the following beacon content in Wireshark,
[04:07.260 --> 04:13.700]  we can see that it contains the maximum transmit power that is allowed in a certain country. And
[04:13.700 --> 04:20.840]  on top of that, the beacon can even further lower the maximum transmit power below this
[04:20.840 --> 04:28.700]  regulatory maximum. In other words, to simplify, an access point can command the client into using
[04:28.860 --> 04:36.420]  a certain maximum transmit power. An adversary can abuse this by forging a beacon that instructs
[04:36.420 --> 04:42.620]  clients into using an extremely low transmission power. In turn, this causes the network connection
[04:42.620 --> 04:49.880]  of the victim to become almost unusable. That's because the frames that the victim is transmitting
[04:49.880 --> 04:56.240]  will no longer reach the access point. Essentially, this means the client will no longer have a stable
[04:56.240 --> 05:03.440]  internet connection. So if we look in practice, we tested this attack against various operating
[05:03.440 --> 05:11.880]  systems, and we found that an iPad on a MacBook was vulnerable to an attack, and Linux was also
[05:11.880 --> 05:20.300]  vulnerable to attacks. Other devices were not affected. It is unclear why, although we conjecture
[05:20.300 --> 05:27.500]  that after injecting forged beacons, other devices may reset their parameters back to normal once
[05:27.500 --> 05:36.320]  they receive a legitimate beacon. Now, we also found a minor variant of this attack against
[05:36.320 --> 05:43.740]  Linux. Namely, when we were inspecting the source code of the Linux kernel, we noticed that it's
[05:43.740 --> 05:52.380]  also able to parse a vendor-specific information element that belonged to Cisco. And what's
[05:52.380 --> 06:00.540]  interesting about this implementation in Linux is that normally, if we follow the specification,
[06:00.540 --> 06:07.140]  we cannot set a negative maximum transmission power. But by abusing this vendor-specific element
[06:07.140 --> 06:16.260]  of Cisco, we can. And it turns out that if we are able to set a negative transmission limit,
[06:16.260 --> 06:22.140]  then the drivers of Linux do not handle this properly, and as a result, they forcibly are
[06:22.140 --> 06:29.800]  disconnected from the network. So let's show a demonstration of this. In our demo, we can see now
[06:29.800 --> 06:35.960]  that the victim has a stable internet connection. However, as an adversary, we're now going to
[06:35.960 --> 06:43.060]  inject 10 beacons to make sure at least one of them arrives at the victim. And if we now look
[06:43.060 --> 06:49.880]  at the debug messages of the victim, we can see that it indeed lowered its transmission power.
[06:50.060 --> 06:55.060]  And if we look in Wireshark, if we look at the spoofed beacon, it now indeed contains this
[06:55.060 --> 07:00.340]  power-constrained element that reduces the transmission power of the client.
[07:00.340 --> 07:06.440]  If the victim now tries to refresh the website or visit a new one, you will see that
[07:06.440 --> 07:11.670]  the website is no longer loading, meaning our attack was successful.
[07:13.720 --> 07:20.170]  Now, a second attack we discovered is that we can lower a victim's bandwidth by spoofing beacons.
[07:20.700 --> 07:28.360]  And this abuses the way that a normal Wi-Fi device transmits frames. In particular, before a Wi-Fi
[07:28.360 --> 07:35.660]  device will transmit a frame, it will first check whether the medium is idle or not. And in case
[07:35.660 --> 07:42.500]  another device is transmitting a frame, it will first wait until this device finished transmitting.
[07:43.140 --> 07:49.300]  And after that, it will wait a very short amount of time called the SIFS interval.
[07:49.520 --> 07:57.100]  And this is mandatory. Every device must wait this amount of time. Additionally, it will wait
[07:57.100 --> 08:02.340]  an amount of time that depends on the priority of the frame that it wants to transmit. This is
[08:02.340 --> 08:11.300]  called the AIFSN period. And for example, if the device wants to send a high priority voice packet,
[08:11.300 --> 08:17.000]  this period is relatively short. While if the device wants to send some background traffic,
[08:17.000 --> 08:24.620]  this period is a bit longer. Then finally, the device will also wait a random amount of time
[08:24.620 --> 08:32.920]  called the backoff window or the contention window. And this is a random value. And it is used to
[08:32.920 --> 08:40.720]  also give other clients an opportunity to transmit as well. In case during these three periods no
[08:40.720 --> 08:48.200]  other device started transmitting, in that case the device can transmit its own frame.
[08:49.050 --> 08:56.480]  Now, what is interesting is that the specific values for these waiting periods are determined
[08:56.480 --> 09:04.220]  by the network configuration. In particular, they are defined by the beacon. So, if we look at a
[09:04.220 --> 09:10.720]  beacon in Wireshark, we can for example see that it advertises the specific value for the AIFSN
[09:10.720 --> 09:19.460]  period. Additionally, the minimum and maximum duration of the backoff window is also defined
[09:19.460 --> 09:26.420]  in the beacon. And of course, as an adversary, we can spoof beacons where these values are very
[09:26.420 --> 09:35.040]  large. And this means we can force a victim into delaying its transmission for a longer amount of
[09:35.040 --> 09:44.080]  time. And this effectively reduces the bandwidth of a victim. Now, the impact can in fact be much
[09:44.800 --> 09:50.760]  higher than simply lowering the bandwidth of a victim. And that's because if another device
[09:50.760 --> 09:58.160]  starts transmitting during any of these waiting periods, then the device will need to completely
[09:58.160 --> 10:04.840]  restart its waiting procedure. In other words, if there is another nearby client that is
[10:05.420 --> 10:11.760]  downloading or uploading a file, our victim may simply never get the chance to transmit the frame
[10:11.760 --> 10:21.280]  and our attack will result in a denial of service. So, we tested this attack in practice and we found
[10:21.280 --> 10:30.100]  that Linux is affected independent of the network card being used. We also tested some Apple devices
[10:30.100 --> 10:35.820]  and here we found that the MacBook Pro, the iPhone, and the iPad are all vulnerable.
[10:36.820 --> 10:44.640]  We also tested Windows 10 and here we noticed that the impact depends on the specific network card
[10:44.640 --> 10:52.940]  that this operating system is using. For example, if we use an alpha or TP-Link USB Wi-Fi dongle,
[10:52.940 --> 10:59.820]  then we found that Windows 10 was vulnerable. However, if we used the built-in network card
[10:59.820 --> 11:06.620]  of certain laptops, which is typically an Intel network card, at least on the devices we tested,
[11:06.620 --> 11:14.400]  then Windows 10 was not vulnerable. Finally, we also tested two Android devices, one more
[11:14.400 --> 11:22.480]  recent Nexus 5X device, and it was vulnerable to our attack. But our fairly old Samsung device
[11:22.480 --> 11:29.100]  was not vulnerable to our attack. So, let's show a demo of this attack in practice.
[11:29.100 --> 11:36.200]  We will target an iPad device and we can see that before starting the attack, the iPad has a
[11:36.200 --> 11:43.160]  throughput of about 10 megabit per second. Then, as an adversary, we will spoof two beacons and if
[11:43.160 --> 11:49.220]  we look in Wireshark, this spoofed beacon has the maximum value for the back-off window and also the
[11:49.220 --> 11:57.240]  maximum value for the AIFSN waiting period as well. And if we now measure the throughput on the iPad,
[11:57.240 --> 12:02.050]  we see that it is substantially lower, meaning our attack has succeeded.
[12:03.220 --> 12:07.860]  We also discovered several other attacks. For instance, we discovered a partial
[12:07.860 --> 12:14.150]  machine-in-the-middle attack, and this attack bypasses channel operating validation in Linux.
[12:14.760 --> 12:20.700]  And for the details, I will refer you to the paper. We also discovered battery depletion attacks,
[12:20.700 --> 12:27.000]  where we can spoof beacons to make clients stay awake longer than they normally are.
[12:27.000 --> 12:32.940]  Additionally, we also found that it is possible to send beacons as unicast frames, and this allows
[12:32.940 --> 12:39.120]  us to target specific clients. This technique worked against all the devices we tested.
[12:40.060 --> 12:46.820]  So how can we prevent these attacks in practice? Well, the idea is to authenticate beacons such
[12:46.820 --> 12:53.080]  that an adversary can no longer spoof them. But before we get into those details, let's first
[12:53.080 --> 13:00.020]  state the goal of our defense. And the goal is to come up with a practical and simple design
[13:00.020 --> 13:06.520]  to encourage adoption in practice. So this means that our cryptographic operations must be
[13:06.520 --> 13:12.620]  efficient, and that the bandwidth overhead must be low as well, because beacons are sent at a low
[13:12.620 --> 13:19.380]  bitrate, and even adding a few bytes will consume a significantly higher airtime.
[13:20.380 --> 13:25.760]  Finally, we also want the defense to be straightforward to implement, because then this
[13:25.760 --> 13:32.820]  increases the chance that vendors will actually adopt our defense in practice. And ideally,
[13:32.820 --> 13:38.220]  we will accomplish this by reusing existing cryptographic primitives that were already used in
[13:38.220 --> 13:46.640]  Wi-Fi. So how can we achieve these design goals? Well, we will rely on symmetric encryption,
[13:46.640 --> 13:53.800]  we will reuse a crypto-primitive that is already part of management frame protection. Additionally,
[13:53.800 --> 14:00.160]  we only defend against outsider attacks. In other words, we assume that the adversary does not
[14:00.160 --> 14:06.560]  possess the credentials of the network. And this assumption is similar to how broadcast
[14:06.560 --> 14:15.880]  on multicast traffic is protected in WPA-213 as well. So concretely, how does our defense work?
[14:15.880 --> 14:22.480]  Well, we add a new type length value element to beacons. This element is shown here,
[14:22.480 --> 14:27.940]  and the two most important fields here are highlighted in green.
[14:28.960 --> 14:33.860]  Now, before I discuss the details of these two important fields, I first want to mention that
[14:33.860 --> 14:38.700]  clients that do not recognize this new type length value element, they will automatically
[14:38.700 --> 14:45.400]  ignore it. This makes our defense backwards compatible with existing Wi-Fi implementations.
[14:45.880 --> 14:52.960]  So first, we have the nonce field. And the nonce field is essentially an incremental number that
[14:52.960 --> 15:00.440]  is used to prevent replay attacks. And then the mic field, which stands for message integrity check,
[15:00.440 --> 15:07.880]  is a CMAQ or GMAQ authentication tag that is calculated over the beacon. And here the CMAQ
[15:07.880 --> 15:14.140]  and GMAQ are existing cryptographic primitives of management frame protection. And the interesting
[15:14.140 --> 15:21.600]  thing is that all WPA3 capable devices are already required to support these operations,
[15:21.600 --> 15:25.980]  meaning vendors will already have implemented them by now.
[15:26.820 --> 15:34.020]  So the remaining question now is, which key will be used to generate this authentication tag?
[15:34.200 --> 15:40.620]  And here we decided to let the access point generate a new beacon protection key when it
[15:40.620 --> 15:47.920]  starts. And this beacon protection key is always sent to the client when it is connecting. In
[15:47.920 --> 15:53.480]  particular, even if the client may not support beacon protection, the access point will still
[15:53.480 --> 15:59.500]  send this beacon key to the client. And older clients will simply ignore this new key,
[15:59.500 --> 16:05.920]  but new clients will treat it as an indication that the access point supports beacon protection.
[16:05.920 --> 16:12.240]  Now the interesting thing about this construction is that an adversary cannot manipulate the
[16:12.240 --> 16:17.700]  handshake that transports the beacon key. This means that downgrade attacks are prevented because
[16:17.700 --> 16:24.060]  an adversary cannot somehow remove the beacon key that is being transported to a client.
[16:25.320 --> 16:31.760]  The final important thing to discuss is how that clients handle beacons that are received before
[16:31.760 --> 16:38.080]  they have connected to a network. Because recall that a client only receives the beacon key once
[16:38.080 --> 16:43.960]  it has connected to the network, meaning that beacons that are received before that cannot be
[16:43.960 --> 16:51.280]  authenticated because the client does not possess the key to verify their authenticity. So how can
[16:51.280 --> 16:59.340]  we handle this in practice? Well, our solution is that before a client connects to a network,
[16:59.340 --> 17:05.640]  it will store one beacon as a reference and it will extract all information of the network
[17:05.640 --> 17:13.140]  from this reference beacon. And when the client now connects to this network and once it has
[17:13.140 --> 17:18.820]  received the beacon protection key, it can take this reference beacon and then verify its
[17:18.820 --> 17:26.020]  authenticity. And in case this check fails, it means there was an attack and then the client
[17:26.020 --> 17:33.100]  can disconnect from the network. On the other hand, if the authenticity of the reference beacon
[17:33.100 --> 17:41.760]  can be successfully validated, then the client can send data frames to the network and can operate
[17:41.760 --> 17:48.540]  as normal. Now that we have our defense, an interesting question is how a client should
[17:48.540 --> 17:53.900]  act when it receives a forged beacon. And we decided that in that case the client should
[17:53.900 --> 17:59.960]  send a notification to the access point. This allows the access point to detect rogue IPs that
[17:59.960 --> 18:07.120]  are far away. For example, in our illustration here, the rogue IP is out of range of the real IP.
[18:07.160 --> 18:13.500]  However, when a client receives a forged beacon from the rogue IP, it can notify the real access
[18:13.500 --> 18:20.220]  point of this and then the real access point can take appropriate actions. So now I want to discuss
[18:20.220 --> 18:26.100]  some practical impact of our research. First and foremost, we created our specification of our
[18:26.100 --> 18:33.340]  defense in collaboration with Intel, Broadcom, Qualcomm, and Huawei. And our defense is now part of the
[18:33.340 --> 18:42.180]  draft IEEE 802.11 standard, meaning vendors will likely adopt this in practice as well. Moreover,
[18:42.180 --> 18:47.860]  the Wi-Fi Alliance has recently expressed interest in our defense as well, meaning it might become
[18:47.860 --> 18:57.140]  part of an update to WPA3 or it might become part of a separate certification program. Our defense
[18:57.140 --> 19:02.940]  is independently also being implemented by Linux, where the kernel generates and verifies authentication
[19:02.940 --> 19:09.540]  tags and host AP manages keys and enables beacon protection if it is supported by the network.
[19:09.560 --> 19:15.320]  We will now show a demo of this on a recent Linux kernel, where if we start the access point and
[19:15.320 --> 19:20.760]  view the beacons in Wireshark, we can indeed see that the authentication tag is being added to
[19:20.760 --> 19:26.640]  beacons. If we now connect to this network, the client will indeed receive the beacon protection
[19:26.640 --> 19:33.520]  key and it will enable beacon protection. As a result, if we now inject a beacon as an adversary,
[19:33.520 --> 19:40.100]  the client will detect this spoofed beacon. In this demo, we made the client print a small debug message,
[19:40.100 --> 19:44.700]  and if we now look at the debug log, we can confirm that the forged beacon has been detected
[19:44.700 --> 19:52.040]  and the attack has been prevented. To conclude our talk, we proposed a defense to prevent
[19:52.040 --> 19:58.040]  outsiders from forging beacons, and our focus on practicality has paid off, because our defense is
[19:58.040 --> 20:04.740]  now part of the 802.11 standard. It is independently being implemented by Linux, and it might become
[20:04.740 --> 20:09.580]  part of an update to WPA3. Thank you for your attention.
